การควบคุมสตรีมด้วย Async Iterator ใน JavaScript: การเจาะลึกการจัดการ Backpressure

ในโลกของการพัฒนาซอฟต์แวร์สมัยใหม่ ข้อมูลเปรียบเสมือนน้ำมันดิบ และมักจะไหลมาอย่างไม่ขาดสาย ไม่ว่าคุณจะกำลังประมวลผลไฟล์ล็อกขนาดใหญ่, รับข้อมูลจาก API feed แบบเรียลไทม์, หรือจัดการกับการอัปโหลดไฟล์ของผู้ใช้ ความสามารถในการจัดการสตรีมข้อมูลอย่างมีประสิทธิภาพไม่ใช่ทักษะเฉพาะทางอีกต่อไป แต่เป็นสิ่งจำเป็น ความท้าทายที่สำคัญที่สุดอย่างหนึ่งในการประมวลผลสตรีมคือการจัดการการไหลของข้อมูลระหว่างผู้ผลิต (producer) ที่รวดเร็วกับผู้บริโภค (consumer) ที่อาจทำงานได้ช้ากว่า หากไม่มีการควบคุม ความไม่สมดุลนี้อาจนำไปสู่การใช้หน่วยความจำเกินขีดจำกัดอย่างรุนแรง, แอปพลิเคชันล่ม, และประสบการณ์ผู้ใช้ที่ย่ำแย่

นี่คือจุดที่ backpressure เข้ามามีบทบาท Backpressure คือรูปแบบหนึ่งของการควบคุมการไหล (flow control) ที่ฝั่งผู้บริโภคสามารถส่งสัญญาณไปยังฝั่งผู้ผลิตให้ทำงานช้าลง เพื่อให้แน่ใจว่าจะได้รับข้อมูลเร็วเท่าที่ตัวเองสามารถประมวลผลได้ทัน เป็นเวลาหลายปีที่การนำ backpressure มาใช้อย่างมีเสถียรภาพใน JavaScript นั้นมีความซับซ้อน และมักจะต้องใช้ไลบรารีภายนอกอย่าง RxJS หรือ Stream API ที่ใช้ callback ที่ซับซ้อน

โชคดีที่ JavaScript สมัยใหม่มีโซลูชันที่ทรงพลังและสวยงามที่ถูกสร้างขึ้นมาในตัวภาษาโดยตรง นั่นคือ Async Iterators เมื่อใช้ร่วมกับลูป for await...of ฟีเจอร์นี้จะมอบวิธีการจัดการสตรีมและ backpressure ที่เป็นธรรมชาติและเข้าใจง่ายโดยอัตโนมัติ บทความนี้จะเจาะลึกในกระบวนทัศน์นี้ โดยจะนำคุณตั้งแต่ปัญหาพื้นฐานไปจนถึงรูปแบบขั้นสูงสำหรับการสร้างแอปพลิเคชันที่ขับเคลื่อนด้วยข้อมูลที่ยืดหยุ่น, ประหยัดหน่วยความจำ, และสามารถขยายขนาดได้

ทำความเข้าใจปัญหาหลัก: น้ำป่าข้อมูล

เพื่อที่จะเข้าใจถึงคุณค่าของโซลูชันได้อย่างเต็มที่ เราต้องเข้าใจปัญหาก่อน ลองนึกภาพสถานการณ์ง่ายๆ: คุณมีไฟล์ข้อความขนาดใหญ่ (หลายกิกะไบต์) และคุณต้องการนับจำนวนคำที่ระบุ วิธีการที่ไม่มีประสิทธิภาพอาจจะเป็นการอ่านไฟล์ทั้งหมดเข้ามาในหน่วยความจำในคราวเดียว

นักพัฒนาที่ยังใหม่กับการจัดการข้อมูลขนาดใหญ่อาจจะเขียนโค้ดลักษณะนี้ในสภาพแวดล้อมของ Node.js:

            // WARNING: Do NOT run this on a very large file!
const fs = require('fs');

function countWordInFile(filePath, word) {
  fs.readFile(filePath, 'utf8', (err, data) => {
    if (err) {
      console.error('Error reading file:', err);
      return;
    }

    const count = (data.match(new RegExp(`\b${word}\b`, 'gi')) || []).length;
    console.log(`The word "${word}" appears ${count} times.`);
  });
}

// This will crash if 'large-file.txt' is bigger than available RAM.
countWordInFile('large-file.txt', 'error');
            

              
                Copy
              
            
          

โค้ดนี้ทำงานได้อย่างสมบูรณ์แบบสำหรับไฟล์ขนาดเล็ก แต่ถ้าไฟล์ large-file.txt มีขนาด 5GB และเซิร์ฟเวอร์ของคุณมี RAM เพียง 2GB แอปพลิเคชันของคุณจะล่มพร้อมกับข้อผิดพลาดหน่วยความจำไม่เพียงพอ (out-of-memory) ผู้ผลิต (ระบบไฟล์) จะส่งข้อมูลทั้งหมดของไฟล์เข้ามาในแอปพลิเคชันของคุณ และผู้บริโภค (โค้ดของคุณ) ไม่สามารถจัดการทั้งหมดได้ในคราวเดียว

นี่คือ ปัญหาคลาสสิกของผู้ผลิต-ผู้บริโภค (producer-consumer problem) ผู้ผลิตสร้างข้อมูลเร็วกว่าที่ผู้บริโภคจะประมวลผลได้ บัฟเฟอร์ที่อยู่ระหว่างทั้งสอง—ในกรณีนี้คือหน่วยความจำของแอปพลิเคชัน—เกิดการล้น Backpressure คือกลไกที่ช่วยให้ผู้บริโภคสามารถบอกผู้ผลิตได้ว่า "เดี๋ยวก่อน ฉันยังทำงานกับข้อมูลชิ้นล่าสุดที่ส่งมาไม่เสร็จ อย่าเพิ่งส่งอะไรมาเพิ่มจนกว่าฉันจะร้องขอ"

วิวัฒนาการของ Asynchronous JavaScript: เส้นทางสู่ Async Iterators

การเดินทางของ JavaScript กับการทำงานแบบอะซิงโครนัสให้บริบทที่สำคัญว่าทำไม async iterators จึงเป็นฟีเจอร์ที่สำคัญมาก

• Callbacks: กลไกดั้งเดิม มีประสิทธิภาพแต่ก็นำไปสู่ "callback hell" หรือ "pyramid of doom" ทำให้โค้ดอ่านและบำรุงรักษายาก การควบคุมการไหลต้องทำด้วยตนเองและมีโอกาสผิดพลาดสูง
• Promises: การปรับปรุงครั้งใหญ่ นำเสนอวิธีที่สะอาดขึ้นในการจัดการการทำงานแบบอะซิงโครนัสโดยการแทนค่าที่จะเกิดขึ้นในอนาคต การเชื่อมต่อด้วย .then() ทำให้โค้ดเป็นเส้นตรงมากขึ้น และ .catch() ช่วยให้การจัดการข้อผิดพลาดดีขึ้น อย่างไรก็ตาม Promises นั้นทำงานทันที (eager)—มันแทนค่าสุดท้ายเพียงค่าเดียว ไม่ใช่สตรีมของค่าที่เกิดขึ้นอย่างต่อเนื่องเมื่อเวลาผ่านไป
• Async/Await: เป็นเหมือนไวยากรณ์สังเคราะห์ (Syntactic sugar) ที่ครอบ Promises อยู่ ทำให้ให้นักพัฒนาสามารถเขียนโค้ดอะซิงโครนัสที่ดูและทำงานเหมือนโค้ดซิงโครนัส มันช่วยปรับปรุงความสามารถในการอ่านโค้ดได้อย่างมาก แต่ก็เหมือนกับ Promises ที่ถูกออกแบบมาโดยพื้นฐานสำหรับการทำงานแบบอะซิงโครนัสครั้งเดียว ไม่ใช่สำหรับสตรีม

แม้ว่า Node.js จะมี Streams API มาเป็นเวลานาน ซึ่งรองรับ backpressure ผ่านการบัฟเฟอร์ภายในและเมธอด .pause()/.resume() แต่มันก็มีช่วงการเรียนรู้ที่สูงชันและมี API ที่แตกต่างออกไป สิ่งที่ขาดหายไปคือวิธีการจัดการสตรีมข้อมูลอะซิงโครนัสที่เป็นส่วนหนึ่งของภาษา ที่มีความง่ายและความสามารถในการอ่านเทียบเท่ากับการวนลูปผ่านอาร์เรย์ธรรมดา นี่คือช่องว่างที่ async iterators เข้ามาเติมเต็ม

ความรู้เบื้องต้นเกี่ยวกับ Iterators และ Async Iterators

เพื่อที่จะเชี่ยวชาญ async iterators การมีความเข้าใจที่มั่นคงเกี่ยวกับคู่หูซิงโครนัสของมันก่อนจะเป็นประโยชน์อย่างยิ่ง

โปรโตคอล Synchronous Iterator

ใน JavaScript อ็อบเจกต์จะถือว่าเป็น iterable (วนซ้ำได้) หากมันปฏิบัติตามโปรโตคอล iterator ซึ่งหมายความว่าอ็อบเจกต์นั้นต้องมีเมธอดที่เข้าถึงได้ผ่านคีย์ Symbol.iterator เมื่อเมธอดนี้ถูกเรียก มันจะคืนค่าอ็อบเจกต์ iterator

อ็อบเจกต์ iterator นั้นจะต้องมีเมธอด next() การเรียก next() แต่ละครั้งจะคืนค่าอ็อบเจกต์ที่มีสองคุณสมบัติ:

• value: ค่าถัดไปในลำดับ
• done: ค่าบูลีนที่เป็น true หากลำดับสิ้นสุดลงแล้ว และเป็น false ในกรณีอื่น ๆ

ลูป for...of เป็นไวยากรณ์สังเคราะห์สำหรับโปรโตคอลนี้ ลองดูตัวอย่างง่ายๆ:

            function makeRangeIterator(start = 0, end = Infinity, step = 1) {
  let nextIndex = start;
  
  const rangeIterator = {
    next() {
      if (nextIndex < end) {
        const result = { value: nextIndex, done: false };
        nextIndex += step;
        return result;
      } else {
        return { value: undefined, done: true };
      }
    }
  };
  return rangeIterator;
}

const it = makeRangeIterator(1, 4);
console.log(it.next()); // { value: 1, done: false }
console.log(it.next()); // { value: 2, done: false }
console.log(it.next()); // { value: 3, done: false }
console.log(it.next()); // { value: undefined, done: true }
            

              
                Copy
              
            
          

แนะนำโปรโตคอล Asynchronous Iterator

โปรโตคอล asynchronous iterator เป็นการต่อยอดที่เป็นธรรมชาติจากคู่หูซิงโครนัสของมัน ข้อแตกต่างที่สำคัญคือ:

1. อ็อบเจกต์ iterable ต้องมีเมธอดที่เข้าถึงได้ผ่าน Symbol.asyncIterator
2. เมธอด next() ของ iterator จะคืนค่าเป็น Promise ที่จะ resolve ไปเป็นอ็อบเจกต์ { value, done }

การเปลี่ยนแปลงง่ายๆ นี้—การห่อหุ้มผลลัพธ์ด้วย Promise—นั้นทรงพลังอย่างไม่น่าเชื่อ มันหมายความว่า iterator สามารถทำงานแบบอะซิงโครนัสได้ (เช่น การร้องขอข้อมูลผ่านเครือข่าย หรือการคิวรีฐานข้อมูล) ก่อนที่จะส่งค่าถัดไป ไวยากรณ์สังเคราะห์ที่สอดคล้องกันสำหรับการใช้งาน async iterables คือลูป for await...of

ลองสร้าง async iterator ง่ายๆ ที่ปล่อยค่าออกมาทุกๆ วินาที:

            const myAsyncIterable = {
  [Symbol.asyncIterator]() {
    let i = 0;
    return {
      next() {
        if (i < 5) {
          return new Promise(resolve => {
            setTimeout(() => {
              resolve({ value: i++, done: false });
            }, 1000);
          });
        } else {
          return Promise.resolve({ done: true });
        }
      }
    };
  }
};

// Consuming the async iterable
(async () => {
  for await (const value of myAsyncIterable) {
    console.log(value); // Logs 0, 1, 2, 3, 4, one per second
  }
})();
            

              
                Copy
              
            
          

สังเกตว่าลูป for await...of หยุดการทำงานในแต่ละรอบการวนซ้ำ เพื่อรอให้ Promise ที่คืนค่ามาจาก next() resolve ก่อนที่จะดำเนินการต่อ กลไกการหยุดรอนี้คือรากฐานของ backpressure

Backpressure ในการทำงานจริงกับ Async Iterators

ความมหัศจรรย์ของ async iterators คือการที่มันใช้ ระบบแบบดึง (pull-based system) ผู้บริโภค (ลูป for await...of) เป็นผู้ควบคุม มันจะ*ดึง*ข้อมูลชิ้นถัดไปอย่างชัดเจนโดยการเรียก .next() แล้วจึงรอ ผู้ผลิตไม่สามารถผลักข้อมูลได้เร็วกว่าที่ผู้บริโภคร้องขอ นี่คือ backpressure ที่มีอยู่ในตัว ซึ่งถูกสร้างขึ้นมาพร้อมกับไวยากรณ์ของภาษา

ตัวอย่าง: ตัวประมวลผลไฟล์ที่รองรับ Backpressure

ลองกลับไปที่ปัญหาการนับคำในไฟล์ของเราอีกครั้ง Node.js streams สมัยใหม่ (ตั้งแต่เวอร์ชัน 10) เป็น async iterable โดยกำเนิด ซึ่งหมายความว่าเราสามารถเขียนโค้ดที่เคยล่มของเราใหม่ให้มีประสิทธิภาพด้านหน่วยความจำได้ด้วยโค้ดเพียงไม่กี่บรรทัด:

            import { createReadStream } from 'fs';
import { Writable } from 'stream';

async function processLargeFile(filePath) {
  const readableStream = createReadStream(filePath, { highWaterMark: 64 * 1024 }); // 64KB chunks

  console.log('Starting file processing...');

  // The for await...of loop consumes the stream
  for await (const chunk of readableStream) {
    // The producer (file system) is paused here. It will not read the next
    // chunk from the disk until this block of code finishes its execution.
    console.log(`Processing a chunk of size: ${chunk.length} bytes.`);

    // Simulate a slow consumer operation (e.g., writing to a slow database or API)
    await new Promise(resolve => setTimeout(resolve, 500));
  }

  console.log('File processing complete. Memory usage remained low.');
}

processLargeFile('very-large-file.txt').catch(console.error);
            

              
                Copy
              
            
          

มาดูกันว่าทำไมมันถึงทำงานได้:

1. createReadStream สร้าง readable stream ซึ่งเป็นผู้ผลิต มันไม่ได้อ่านไฟล์ทั้งไฟล์ในครั้งเดียว มันจะอ่านข้อมูลเป็นชิ้นๆ (chunk) เข้ามาในบัฟเฟอร์ภายใน (ไม่เกินค่า highWaterMark)
2. ลูป for await...of เริ่มทำงาน มันจะเรียกเมธอด next() ภายในของสตรีม ซึ่งจะคืนค่า Promise สำหรับข้อมูลชิ้นแรก
3. เมื่อข้อมูลชิ้นแรกพร้อมใช้งาน เนื้อหาในลูปจะเริ่มทำงาน ภายในลูปเราจำลองการทำงานที่ช้าด้วยการหน่วงเวลา 500 มิลลิวินาทีโดยใช้ await
4. นี่คือส่วนที่สำคัญที่สุด: ในขณะที่ลูปกำลัง `await` มันจะไม่เรียก next() บนสตรีม ผู้ผลิต (file stream) จะเห็นว่าผู้บริโภคกำลังยุ่งและบัฟเฟอร์ภายในเต็ม มันจึงหยุดอ่านข้อมูลจากไฟล์ การจัดการไฟล์ของระบบปฏิบัติการจะถูกพักไว้ชั่วคราว นี่คือ backpressure ในการทำงานจริง
5. หลังจาก 500 มิลลิวินาที `await` ก็เสร็จสิ้น ลูปจะจบการวนซ้ำรอบแรกและเรียก next() อีกครั้งทันทีเพื่อร้องขอข้อมูลชิ้นถัดไป ผู้ผลิตได้รับสัญญาณให้ทำงานต่อและอ่านข้อมูลชิ้นถัดไปจากดิสก์

วงจรนี้จะดำเนินต่อไปจนกว่าไฟล์จะถูกอ่านจนหมด จะไม่มีช่วงเวลาใดที่ไฟล์ทั้งไฟล์ถูกโหลดเข้ามาในหน่วยความจำ เราเก็บข้อมูลเพียงชิ้นเล็กๆ ในแต่ละครั้งเท่านั้น ทำให้การใช้หน่วยความจำของแอปพลิเคชันของเราน้อยและคงที่ ไม่ว่าไฟล์จะมีขนาดใหญ่แค่ไหนก็ตาม

สถานการณ์และรูปแบบขั้นสูง

พลังที่แท้จริงของ async iterators จะถูกปลดล็อกเมื่อคุณเริ่มนำมันมาประกอบกัน สร้างเป็นไปป์ไลน์การประมวลผลข้อมูลที่อ่านง่าย, เป็นแบบ declarative, และมีประสิทธิภาพ

การแปลงสตรีมด้วย Async Generators

ฟังก์ชัน async generator (async function* ()) เป็นเครื่องมือที่สมบูรณ์แบบสำหรับการสร้างตัวแปลง (transformers) มันคือฟังก์ชันที่สามารถทั้งบริโภคและผลิต async iterable ได้

ลองนึกภาพว่าเราต้องการไปป์ไลน์ที่อ่านสตรีมข้อมูลข้อความ, แยกวิเคราะห์ (parse) แต่ละบรรทัดเป็น JSON, และจากนั้นกรองเฉพาะระเบียนที่ตรงตามเงื่อนไขที่กำหนด เราสามารถสร้างสิ่งนี้ได้ด้วย async generators ขนาดเล็กที่นำกลับมาใช้ใหม่ได้

            // Generator 1: Takes a stream of chunks and yields lines
async function* chunksToLines(chunkAsyncIterable) {
  let previous = '';
  for await (const chunk of chunkAsyncIterable) {
    previous += chunk;
    let eolIndex;
    while ((eolIndex = previous.indexOf('\n')) >= 0) {
      const line = previous.slice(0, eolIndex + 1);
      yield line;
      previous = previous.slice(eolIndex + 1);
    }
  }
  if (previous.length > 0) {
    yield previous;
  }
}

// Generator 2: Takes a stream of lines and yields parsed JSON objects
async function* parseJSON(stringAsyncIterable) {
  for await (const line of stringAsyncIterable) {
    try {
      yield JSON.parse(line);
    } catch (e) {
      // Decide how to handle malformed JSON
      console.error('Skipping invalid JSON line:', line);
    }
  }
}

// Generator 3: Filters objects based on a predicate
async function* filter(asyncIterable, predicate) {
  for await (const value of asyncIterable) {
    if (predicate(value)) {
      yield value;
    }
  }
}

// Putting it all together to create a pipeline
async function main() {
  const sourceStream = createReadStream('large-log-file.ndjson');

  const lines = chunksToLines(sourceStream);
  const objects = parseJSON(lines);
  const importantEvents = filter(objects, (event) => event.level === 'error');

  for await (const event of importantEvents) {
    // This consumer is slow
    await new Promise(resolve => setTimeout(resolve, 100)); 
    console.log('Found an important event:', event);
  }
}

main();
            

              
                Copy
              
            
          

ไปป์ไลน์นี้สวยงามมาก แต่ละขั้นตอนเป็นหน่วยย่อยที่แยกจากกันและสามารถทดสอบได้ ที่สำคัญกว่านั้นคือ backpressure จะถูกรักษาไว้ตลอดทั้งห่วงโซ่ หากผู้บริโภคคนสุดท้าย (ลูป for await...of ใน main) ทำงานช้าลง generator `filter` จะหยุดชั่วคราว ซึ่งทำให้ generator `parseJSON` หยุดชั่วคราวตามไปด้วย และนั่นทำให้ `chunksToLines` หยุดชั่วคราว และสุดท้ายส่งสัญญาณให้ `createReadStream` หยุดอ่านข้อมูลจากดิสก์ แรงกดดันนี้จะถูกส่งย้อนกลับไปตลอดทั้งไปป์ไลน์ จากผู้บริโภคไปยังผู้ผลิต

การจัดการข้อผิดพลาดใน Async Streams

การจัดการข้อผิดพลาดนั้นตรงไปตรงมา คุณสามารถครอบลูป for await...of ของคุณด้วยบล็อก try...catch หากส่วนใดส่วนหนึ่งของผู้ผลิตหรือไปป์ไลน์การแปลงเกิดข้อผิดพลาด (หรือคืนค่า Promise ที่ถูก reject จาก next()) ข้อผิดพลาดนั้นจะถูกจับโดยบล็อก catch ของผู้บริโภค

            async function processWithErrors() {
  try {
    const stream = getStreamThatMightFail();
    for await (const data of stream) {
      console.log(data);
    }
  } catch (error) {
    console.error('An error occurred during streaming:', error);
    // Perform cleanup if necessary
  }
}
            

              
                Copy
              
            
          

การจัดการทรัพยากรอย่างถูกต้องก็เป็นสิ่งสำคัญเช่นกัน หากผู้บริโภคตัดสินใจที่จะออกจากลูปก่อนเวลา (โดยใช้ break หรือ return) async iterator ที่ดีควรมีเมธอด return() ลูป for await...of จะเรียกเมธอดนี้โดยอัตโนมัติ ทำให้ผู้ผลิตสามารถทำความสะอาดทรัพยากรต่างๆ เช่น การปิดไฟล์ หรือการยกเลิกการเชื่อมต่อฐานข้อมูลได้

กรณีการใช้งานในโลกแห่งความเป็นจริง

รูปแบบ async iterator นั้นมีความหลากหลายอย่างไม่น่าเชื่อ นี่คือกรณีการใช้งานทั่วไปที่มันทำงานได้ดีเยี่ยม:

• การประมวลผลไฟล์และ ETL: การอ่านและแปลงไฟล์ CSV, ล็อก (เช่น NDJSON), หรือไฟล์ XML ขนาดใหญ่สำหรับงาน Extract, Transform, Load (ETL) โดยไม่ใช้หน่วยความจำมากเกินไป
• Paginated APIs: การสร้าง async iterator ที่ดึงข้อมูลจาก API ที่มีการแบ่งหน้า (paginated) (เช่น ฟีดโซเชียลมีเดีย หรือแคตตาล็อกสินค้า) iterator จะดึงข้อมูลหน้า 2 ก็ต่อเมื่อผู้บริโภคประมวลผลหน้า 1 เสร็จแล้ว ซึ่งจะช่วยป้องกันการยิง API ถี่เกินไปและทำให้การใช้หน่วยความจำต่ำ
• ฟีดข้อมูลแบบเรียลไทม์: การบริโภคข้อมูลจาก WebSockets, Server-Sent Events (SSE), หรืออุปกรณ์ IoT Backpressure ช่วยให้แน่ใจว่าตรรกะของแอปพลิเคชันหรือ UI ของคุณจะไม่ถูกท่วมท้นด้วยข้อความที่เข้ามาพร้อมกันจำนวนมาก
• Database Cursors: การสตรีมข้อมูลหลายล้านแถวจากฐานข้อมูล แทนที่จะดึงชุดผลลัพธ์ทั้งหมด database cursor สามารถถูกห่อหุ้มด้วย async iterator เพื่อดึงข้อมูลทีละแถวเป็นชุดๆ ตามที่แอปพลิเคชันต้องการ
• การสื่อสารระหว่างเซอร์วิส: ในสถาปัตยกรรมแบบไมโครเซอร์วิส เซอร์วิสต่างๆ สามารถสตรีมข้อมูลหากันโดยใช้โปรโตคอลอย่าง gRPC ซึ่งรองรับการสตรีมและ backpressure โดยกำเนิด และมักจะถูกนำไปใช้ด้วยรูปแบบที่คล้ายกับ async iterators

ข้อควรพิจารณาด้านประสิทธิภาพและแนวทางปฏิบัติที่ดีที่สุด

แม้ว่า async iterators จะเป็นเครื่องมือที่ทรงพลัง แต่ก็เป็นสิ่งสำคัญที่จะต้องใช้งานอย่างชาญฉลาด

• ขนาดของ Chunk และ Overhead: การ await แต่ละครั้งจะเพิ่ม overhead เล็กน้อยในขณะที่ JavaScript engine หยุดและกลับมาทำงานต่อ สำหรับสตรีมที่มีปริมาณข้อมูลสูงมาก การประมวลผลข้อมูลในขนาด chunk ที่เหมาะสม (เช่น 64KB) มักจะมีประสิทธิภาพมากกว่าการประมวลผลทีละไบต์หรือทีละบรรทัด นี่คือการแลกเปลี่ยนระหว่างความหน่วง (latency) และปริมาณงาน (throughput)
• การทำงานพร้อมกันแบบควบคุม: Backpressure ผ่าน for await...of นั้นทำงานแบบตามลำดับโดยเนื้อแท้ หากงานประมวลผลของคุณเป็นอิสระต่อกันและขึ้นอยู่กับ I/O (เช่น การเรียก API สำหรับแต่ละรายการ) คุณอาจต้องการเพิ่มการทำงานแบบขนานที่ควบคุมได้ คุณสามารถประมวลผลรายการเป็นชุดโดยใช้ Promise.all() แต่ต้องระวังไม่ให้สร้างคอขวดใหม่โดยการทำให้เซอร์วิสปลายทางทำงานหนักเกินไป
• การจัดการทรัพยากร: ตรวจสอบให้แน่ใจเสมอว่าผู้ผลิตของคุณสามารถจัดการกับการถูกปิดอย่างไม่คาดคิดได้ สร้างเมธอด return() (ซึ่งเป็นทางเลือก) บน iterator ที่คุณสร้างขึ้นเองเพื่อทำความสะอาดทรัพยากร (เช่น ปิดไฟล์, ยกเลิกการร้องขอผ่านเครือข่าย) เมื่อผู้บริโภคหยุดทำงานก่อนเวลาอันควร
• เลือกเครื่องมือที่เหมาะสม: Async iterators เหมาะสำหรับการจัดการลำดับของค่าที่มาถึงเมื่อเวลาผ่านไป หากคุณเพียงแค่ต้องการรันงานอะซิงโครนัสที่เป็นอิสระต่อกันจำนวนที่แน่นอน Promise.all() หรือ Promise.allSettled() ยังคงเป็นตัวเลือกที่ดีกว่าและง่ายกว่า

บทสรุป: การยอมรับในกระแสข้อมูล

Backpressure ไม่ใช่แค่การปรับปรุงประสิทธิภาพเท่านั้น แต่เป็นข้อกำหนดพื้นฐานสำหรับการสร้างแอปพลิเคชันที่แข็งแกร่งและเสถียรที่สามารถจัดการกับข้อมูลปริมาณมากหรือไม่สามารถคาดเดาได้ async iterators ของ JavaScript และไวยากรณ์ for await...of ได้ทำให้แนวคิดที่ทรงพลังนี้เข้าถึงได้ง่ายขึ้น โดยย้ายมันจากขอบเขตของไลบรารีสตรีมเฉพาะทางมาสู่แกนกลางของภาษา

ด้วยการยอมรับโมเดลแบบดึง (pull-based) และเป็นแบบ declarative นี้ คุณจะสามารถ:

• ป้องกันหน่วยความจำล่ม: เขียนโค้ดที่มีการใช้หน่วยความจำน้อยและคงที่ โดยไม่คำนึงถึงขนาดของข้อมูล
• ปรับปรุงความสามารถในการอ่านโค้ด: สร้างไปป์ไลน์ข้อมูลที่ซับซ้อนที่อ่านง่าย, ประกอบง่าย, และทำความเข้าใจได้ง่าย
• สร้างระบบที่ยืดหยุ่น: พัฒนาแอปพลิเคชันที่สามารถจัดการการควบคุมการไหลระหว่างส่วนประกอบต่างๆ ได้อย่างราบรื่น ตั้งแต่ระบบไฟล์และฐานข้อมูลไปจนถึง API และฟีดข้อมูลแบบเรียลไทม์

ครั้งต่อไปที่คุณต้องเผชิญกับข้อมูลปริมาณมหาศาล อย่าเพิ่งรีบไปหาไลบรารีที่ซับซ้อนหรือวิธีแก้ปัญหาแบบเฉพาะหน้า แต่ให้ลองคิดในแง่ของ async iterables การปล่อยให้ผู้บริโภคดึงข้อมูลตามจังหวะของตัวเอง จะทำให้คุณเขียนโค้ดที่ไม่เพียงแต่มีประสิทธิภาพมากขึ้น แต่ยังสวยงามและบำรุงรักษาได้ง่ายขึ้นในระยะยาวอีกด้วย